gnrc_sixlowpan_frag: allow send of multiple datagrams simultaneously #11021
Conversation
miri64
added
Type: enhancement
|
#11068 is too experimental so it doesn't make any sense to try too get this into the release => post-poned. |
The VRB also needs to be able to generate new tags for forwarding. This exposes the tag generation.
miri64
force-pushed
the
gnrc_sixlowpan_frag/enh/multiple-send
branch
from
3b426cd
to
4b529d9
Compare
|
Rebased to current master and moved compile configurations to |
There was a problem hiding this comment.
The code looks good, tested on the iotlab testbed using 2 nodes. The normal operation still works. I then compiled with GNRC_SIXLOWPAN_MSG_FRAG_SIZE=2 and reduced the ping interval in order to get interleaving ping fragments.
With below configuration pinging works:
ping6 -c 100 -i 200 -s 1232 ...With below configuration pinging does not work:
ping6 -c 100 -i 100 -s 1232 ...I assume that with a payload of 1232 I trigger ~10 fragments with an average RTT of ~100ms.
While a pinging interval of 200ms yields almost 100% success, pinging with 100ms yields 0% success. I can't tell whether it's just because of a too small fragmentation buffer.
Nevertheless, the proposed change is sane and the default is to handle 1 datagram at a time anyways. ACK from my side.
|
The effect has nothing to do with the new feature. The same will be visible on master, as you are sending huge packages faster than the node can handle them (RTT for those pings alone is >100ms |
yes, but I would expect at least some pings to succeed. I see 0% success. |
miri64
force-pushed
the
gnrc_sixlowpan_frag/enh/multiple-send
branch
from
4b529d9
to
93050d2
Compare
|
Squashed |
How could a ping succeed, if you are draining the pinged nodes resources in one instance? The "problem" is the new asynchronous ping here. It doesn't wait for a reply until it sends the next package, like the old ping did and thus makes such effects more visible. See also RIOT-OS/Release-Specs#121 for what is happening. Anyway, this is unrelated to this PR. You won't be able to force the 6LoWPAN thread to send multiple datagrams just with one node. You need fragment forwarding to observe this. |
so it's currently not possible to test this new feature with this PR alone? Nevertheless, I confirmed that it at least does not break the current master's behaviour. |
Yepp, that's why the testing procedures say
;-) |
miri64
added
the
CI: ready for build
Contribution description
For fragment forwarding I need to be able to send (and in case the packet is compressed also [re-]construct) fragments of multiple datagrams. Currently this is not possible, since the source for the datagram tag is always taken from the global variable
_tag. However, by adding thetagto thegnrc_sixlowpan_msg_frag_ttype we are able to allocate a datagram tag from_tagat an earlier point and use the new member to set the fragments datagram tag field from that.I also piggy-backed some optimizations to the
gnrc_sixlowpan_fragmodule, which results in this enhancement only to require 20 more bytes of code.Testing procedure
gnrc_networkingshould still be able to ping between two 6Lo-capable nodes with large payloads.Issues/PRs references
No dependencies, but provides basis for others: